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VERIFICATION OF SOFTWARE AGENTS 
AND AGENT ACTIVITIES 

BACKGROUND 

This invention relates to verification of software agents 
and their activities, and particularly to verification of soft- 
ware agents and their activities in a distributed computing 
environment. 

In information -intensive computing environments, users 
tend both to be subject to information overload and to 
consume computing resources inefficiently. Toward allevi- 
ating such overload and inefficiency, software programmers 
have constructed programs commonly known as software 
agents. Indeed, software agents are well-known user tools. 

Typically, software agents are entrusted to accomplish one 
or more tasks, e.g., on behalf of a user. As an example, some 
software agents are entrusted to search, filter, analyze and 
assign priorities to information. As another example, some 
software agents are entrusted with sensitive tasks and asso- 
ciated information, such as banking tasks and associated 
account information, e-commerce tasks and associated 
credit card information, and other transactions with trade 
secret or trade sensitive information. 

Toward accomplishing tasks, software agents typically 
exercise the computing environment, e.g., to obtain services 
managed by servers and/or to interact with other agents. 
Under such conditions, a software agent is variously subject 
to corruption. As an example, a software agent can be 
rendered corrupting (e.g., made malicious) such as by 
changing its code to incorporate a virus or to provide other 
undesirable functionality. An agent corrupted by a virus 
typically is enabled to spread the virus in the computing 
environment (e.g., to servers) and/or to other agents with 
which it interacts. 

As another example, a software agent can itself be 
corrupted, such as by a change in its code as to either an 
entrusted task or task -associated information. In the case of 
an agent entrusted with a bank transfer task, the agent is 
corrupted if its code is changed to alter the nature or amount 
of the transfer. 

As yet another example, the software agent is without 
corruption, but the agent is functionally/indirectly corrupted 
by malicious operation within a part of the environment 
being exercised. To illustrate this example, an agent 
entrusted with a bank transfer task likely will carry infor- 
mation requesting that the transfer be of a fixed amount and 
be effected from a first account to a second account. 
However, the agent can be corrupted by maliciousness 
present in the transfer server itself. The agent's corruption in 
this case can be a change in the task's implementation, such 
as by (i) transferring a different amount or (ii) directing the 
amount to a third account, or (ii) both. The agent's corrup- 
tion is compounded if accompanied by false reporting — to 
or through the agent, or otherwise — that the requested task 
was properly implemented. 

Agent corruption generally is insufficiently protected via 
encryption techniques. That is, while encryption techniques 
can verify the origin of a software agent, these techniques 
typically have limited capability to deter corruption. In 
particular, encryption techniques generally fall short in 
deterring agent corruption if such corruption can occur prior 
to encryption or after decryption. 

Accordingly, there is need in the art for methods and 
apparatus that verify software agents and their activities in 
a distributed computing environment. In particular, there is 
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a need for such methods and apparatus where malicious 
operation may be present in the environment. 

SUMMARY 

5 The present invention provides an apparatus and method 
to verify software agents and their activities. In a distributed 
computing environment, an origin resource, a destination 
resource and a trusted resource are provided. The origin 
resource is associated with a software agent in that, most 

10 generally, the agent's information and/or an entrusted task 
are relevant to the origin resource. The origin resource, 
typically, provides information and/or entrusts task(s) to the 
software agent and expects to receive a report, either of 
information about or of the result of the agent's activities, 

15 via either return of the agent or otherwise. 

The origin resource typically launches a software agent. 
However, a software agent may be associated with one or 
more origin resources and, as such, may be initially 
launched by any of such resources or by some other resource 

20 (e.g., a software agent could be launched initially by a 
trusted or a destination resource). 

The destination resource is associated with the software 
agent in that, most generally, it is expected to advance the 

25 agent in the performance of an entrusted task. Typically, the 
destination resource receives the agent, interacts with it and 
performs and/or contributes to the performance of one or 
more of the agent's entrusted tasks. Any one software agent 
may have one or more associated destination resources. 

30 The trusted resource is associated with the software agent 
in that the trusted resource functions to provide verification 
of the software agent and its activities. The trusted resource 
preferably has associated therewith selected mechanisms 
that support one or more selected operations such as, for 

35 example: receiving/forwarding of software agents; 
encrypting/decrypting part(s) of or entire software agents; 
acquiring, storing, retrieving and comparing of software 
agent fingerprints; executing rules, including for checking 
variable information; establishing, setting, updating and 

40 checking return timers; generating verification notices, 
reports or other return relevant to verification of the agent 
and its activities, such verification return typically being 
directed to an origin resource and/or the launching resource; 
logging the activities of software agents with which it 

45 interacts; and stripping, masking, or otherwise protecting 
part(s) or all of a software agent. 

A trusted resource preferably is non-corruptible. Toward 
that, the trusted resource's resident hardware and/or soft- 
ware preferably effect security of the trusted resource itself. 

50 This security-directed hardware/software protects the 
trusted resource, e.g., from viruses and other corrupting 
influences, whether introduced through software agents or 
otherwise. Moreover, assuming some corruption may occur 
respecting the trusted resource, the security-directed 

55 hardware/software preferably enables identifying and cor- 
recting any such corruption, including of any operating 
system and application software associated with the trusted 
resource. 

The present invention also provides a software agent 
60 configured so as to be capable of verification using the 
apparatus and methods of this invention. Any such agent 
preferably has one or more fixed and variable fields. Fixed 
fields typically support addresses, rules, data or other fixed 
information (information that does not change regardless of 
65 the task(s) the agent is entrusted to accomplish). Variable 
fields typically support operational flags (e.g., a new/old 
flag), rules, data or other variable information (information 
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that changes as the agent accomplishes its entrusted lask(s)). location or among a plurality of distributed, physical loca- 
Any such agent preferably also supports certain rules, tions in or associated with the computing environment. As 
including rules that enable selected operations, such as, for an example, the trusted resource can be implemented as a 
example, checking for appropriate modifications of variable server resident at one site in a network, the site typically 
information and/or ensuring that the TR rules themselves are 5 comprising a computing device, wherein the server is con- 
not corrupted. figured to interact (directly or indirectly) with selected 

software agents as such agents exercise the environment, 

DESCRIPTION OF THE DRAWINGS e.g., by traversing from (or to) the origin resource and to (or 

Tne invention can be better understood with reference to from) the destination resource. As another example, the 

the following detailed description together with the 10 trusted ^source can be implemented as a one or more 

appended illustrative drawings in which like elements are servers havm ^ distributed residence among various sites in 

L i 7i_ one or more networks of the computing environment. Not- 

withstanding these two examples, it is to be understood that 
FIG. 1 is a block diagram illustrating a distributed com- tne trusted resource may be otherwise implemented without 
puting environment in accordance with the present inven- departing from the principles of the invention, 
tion; 15 An origin resource is associated with a software agent 
FIG. 2 is a block diagram illustrating a trusted resource in where, most generally, the agent's information and entrusted 
accordance with the present invention; task(s) are, or are capable of becoming, relevant to the origin 
FIG. 3 is a flowchart illustrating the steps of verifying a resource. An origin resource, typically, specifies an agent by 
software agent and its activities in connection with a trusted Priding information and/or entrusting task(s) to the soft- 
resource in accordance with the present invention; and 20 ware a f nt ' on S m resource entrusts tasks by (a) provid- 
jg . « i * «. ... ~~ . . . mg tasks, e.g., m the form of code, (b) selecting among 
FIG. 4 is a block diagram illustrating a software agent ,n Q | ered ^ . f ^ fc b B anoth( f r 

accordance with the present invention. resource> ^ ^ , rasted & destination or 

DETAILED DESCRIPTION a second origin resource, (c) a combination of (a) and (b), or 

Overview 25 (d) otherwise. (An origin resource is sometimes abbreviated 

Verification of software agents and their activities com- herein as "OR"), 
prises determining whether software agent information and An origin resource, typically, expects to receive a report 
tasks are corrupted. The terms "corruption", and its variants, based on an agent's exercising the computing environment, 
as used herein, refer to, without exhaustion, any or all of (i) such report being either of information about or of the result 
misdirection or redirection of the agent, (ii) incorporation of 30 of the agent's activities. It is to be understood, however, that 
virus code or other undesirable functionality in or with the a software agent entrusted with tasks or information pro- 
agent, (iii) replacement or other impersonation of the agent, vided by or for a particular origin resource may also be 
(iv) other modification, supplementation or alteration — in entrusted with information and/or tasks relevant to one or 
whole or in part — of the agent (e.g., its tasks and/or more other origin resources. 

information) in an inappropriate, impermissible or unautho- 35 An origin resource preferably is capable of launching a 

rized manner, and/or (v) deviation from the expected imple- software agent. However, it is to be understood that a 

mentation of the agent's tasks (with or without false report- software agent relevant to a particular origin resource may 

ing of the implementation). be initially launched by other than that origin resource. As 

Verification of software agents and their activities tends to an example, a software agent may be launched by a second 

have enhanced value as agents and their activities gain 40 origin resource, either for purposes that are relevant to the 

criticality. Criticality tends to exist, for example, where first and second origin resources or solely on behalf of the 

agents are entrusted with sensitive/confidential tasks and first origin resource. As another example, the software agent 

associated information, such as: a) banking tasks and asso- may be launched initially by a trusted resource, e.g., respon- 

ciated account information; b) e-commerce tasks and asso- sive to either an origin resource or a destination resource, or 

ciated credit card information; and c) other transactions with 45 at the initiative of the trusted resource itself (e.g., so as to 

trade secret or trade sensitive information. effectively provide its services), or otherwise. As yet another 

According to the invention, verification apparatus and example, the software agent may be launched initially by a 

methods operate in, and/or are part of, a computing envi- destination resource, e.g., responsive to either an origin 

ronment. Preferably, such computing environment com- resource or a trusted resource, or at the initiative of the 

prises a distributed computing environment, such as the 50 destination resource itself (e.g., so as to promote its 

Internet, or an Internet-like system, or the World Wide Web, services), or otherwise. In this latter most example, the 

or a World- Wide- Web- like system, or any open communi- destination resource itself may be an effective origin 

cation networks or services, or any other environment resource and, in which case, the origin resource (or trusted 

wherein software agents may be subject to corruption, resource) may be an effective destination resource — i.e., the 

including by malicious operation within a part of the envi- 55 destination resource may provide information and/or entrust 

ronment itself. tasks to an agent that implicate action at the origin resource 

Broadly, the apparatus and methods of the invention (e.g., by an end user), 

contemplate an origin resource, a destination resource and a From such examples, it should be understood that a 

trusted resource. Each of the origin, destination and trusted software agent may be associated with one or more origin 

resources comprises any one or more of a site, a server, 60 resources and may be initially launched by any of such 

software applications, software agents, networks, firmware, resources or by any other resource, without departing from 

or other hardware, software or network resources (physical the principles of the invention. In any case, it should be 

and/or logical), alone or in combination (referred to understood that a software agent is launched so as to be 

hereinafter, generally, as "hardware, software and/or net- capable of ultimately becoming relevant to an origin 

work resources"). 65 resource. 

It is to be understood that each such origin, destination A destination resource is associated with the software 

and trusted resource can be implemented in/at one physical agent in that, most generally, it is expected to effect an 
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entrusted task. Typically, the destination resource receives Further to this embodiment, the origin resource comprises 

the agent, interacts with it and performs and/or contributes an Internet client, the client being enabled to specify and 

to the performance of a portion or all of one or more of the launch software agents and, typically, being operated by an 

agent's entrusted tasks (hereinafter, "perform" is generally end user. After the origin resource launches a software agent, 

used to indicate, as to a task, both actual performance and 5 the agent exercises the computing environment and, 

contributing to the performance of a task). However, it is to accordingly, the origin resource typically loses control of the 

be understood that any one software agent may have one or agent. If the agent encounters a corrupting influence within 

more associated destination resources. As an example, an any part of the environment it exercises, the software agent's 

agent's plural destination resources can be organized (a) entrusted task(s) or information can be variously corrupted, 

individually so that each can perform any one or a plurality 10 However, any such corruption generally remains unknown 

of tasks or (b) in variously-composed groups so that any at the launching origin resource and/or at any other origin 

particular group can perform any one of a plurality of tasks. resource(s) for which the agent is relevant. Moreover, even 

(A destination resource is sometimes abbreviated herein as if the corruption becomes reported to an origin resource, 

"DR".) such report generally can be expected to occur at a time 

A trusted resource is associated with the software agent in 15 sufficiently subsequent to the corruption that corrective 

that the software agent and the trusted resource functions to action is unavailing (e.g., foreclosed is either/both proper 

provide verification of the software agent and its activities. completion of the entrusted task and the identification and 

The trusted resource preferably supports one or more eradication of any malicious operation), 

selected verification operations. Examples of verification In exercising the computing environment in this example 

operations include, without exhaustion: receiving/ 20 embodiment, a software agent typically uses one or more of 

forwarding of software agents; encrypting/decrypting part(s) the communication paths to traverse among the origin 

of or entire software agents; acquiring, storing, retrieving resource, the trusted resource and the destination resource, 

and comparing of software agent fingerprints; executing In the case of the Internet, the exercise engenders the 

rules, including for checking variable information; software agent being routed/switched from one site or server 

establishing, setting, updating and checking return timers; 25 to the next based on understood operation of protocols, e.g., 

generating verification notices, reports or other return rel- the Internet protocol ("IP"). In such case, the origin, desti- 

evant to verification of the agent and its activities, such nation and trusted resources support IP. It is to be understood 

verification return typically being directed to an origin that various protocols can be used, alone or together, in 

resource and/or the launching resource; logging the activi- substitution for or to supplement IP, depending on the 

ties of software agents with which the trusted resource 30 computing environment and that, generally, the origin, des- 

interacts; and stripping, masking, or otherwise protecting tination and trusted resources support the implicated 

part(s) or all of a software agent. (The term "fingerprint", as protocol(s), without departing from the principles of the 

used in this document, refers to a software agent's invention. 

fingerprint, signature, profile, or other touchstone Although the sequence, services and operation of, or 

information, individually and collectively, as well as to the 35 associated with, traverse among resources may vary by 

act of acquiring same.) exercise and/or implementation, it is to be understood that 

A trusted resource preferably is non-corruptible. Toward verification of the software agent is to be supported in 

that, the trusted resource preferably effects security of the accordance with this invention. In particular, it is contem- 

trusted resource itself. That is, the trusted resource prefer- plated that the software agent be subject to verification 

ably comprises hardware, software and/or network resources 40 operations relating to at least two verification events: the 

directed to protect the TR, e.g., from viruses and other first verification event relying on the agent's state absent any 

corrupting influences, whether introduced through software interaction with a resource that performs a task, and the 

agents or otherwise. Moreover, assuming corruption may second verification event relying on the agent's state subject 

occur respecting the trusted resource, the trusted resource to any interaction with a resource that performs a task, 

preferably is enabled to identify and correct any such 45 So as to ensure the verification events, each traverse 

corruption, including of any operating system and applica- among the OR, DR and TR generally contemplates the 

tion software associated with the trusted resource. agent's interaction with/at the trusted resource. Typically, 

Example Embodiment the software agent is directed from an origin resource to, and 

In one example embodiment, the trusted resource com- is ultimately received by/at, the trusted resource and, 
prises a trusted server linked to and/or in a computing 50 therefrom, the software agent is directed to, and is ultimately 
environment. The destination and origin resources, as well, received by/at, the destination resource. Also typical is that, 
are linked to and/or in the computing environment. In each from a destination resource, the software agent is directed to, 
case, the link is via respective communication paths, which and is ultimately received by/at, the trusted resource and, 
paths also comprise part of or are associated with the therefrom, the software agent is directed to, and is ultimately 
computing environment. In an example case, the computing 55 received by/at, the origin resource. Yet also typical is that a 
environment comprises the Internet, and the communication software agent is directed from the trusted resource follow- 
paths comprise any of a plurality of communication ing some interaction, e.g., the trusted resource's perfor- 
resources, alone and in various combinations, including fiber mance of appropriate verification operations on or in con- 
optic cables, twisted pair telephone lines, coaxial cabling, nection with the agent, 
switching and routing circuitry, processes for such switching 60 Resource Mechanisms 

and routing, protocols, firmware, and other hardware, soft- The trusted resource preferably has associated therewith 

ware and/or network resources. selected hardware, software and/or network resources that 

In this embodiment, a destination resource comprises a support one or more selected verification operations. The 

server associated with an Internet site, the site supporting hardware, software, and network resources, alone and in 

certain operations and functions (e.g., a bank's World Wide 65 various combinations, comprise a plurality of mechanisms. 

Web site providing a gateway to the bank's services, Typical trusted resource mechanisms include: (a) a receipt 

including, for example, transfers to and from user accounts). mechanism; (b) a forwarding mechanism; (c) a fingerprint 
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acquisition mechanism; (d) a fingerprint storage mechanism; A forwarding mechanism enables the trusted resource to 
(e) a fingerprint comparison mechanism; (f) a verification communicate in the computing environment. In particular, it 
return mechanism; (g) a timer mechanism; (h) a trusted enables software agents to traverse from the trusted 

resource rules mechanism; (i) a logging mechanism; j) a resource. Such traverse generally is, ultimately, to one or 

housekeeping mechanism; (k) an administration mecba- 5 more appropriate destination resources or origin resources. 

S JL? aTkIS-hIi (m T Ty? T To d0 *>> the fonvarding mechanism preferably operates in 

t ^ ™. Mih0 »& hsled "^dually, it is o be under- agreem ent with applicable protocols, 

stood that the mechanisms can be implemented individually, A r KF . . F ^ , , . 

or in one or more combinations, or otherwise, without fonwidmg mechamsm can be implemented m various 

departing from the principles of the invention. way f * M a ° exam P le » the forwarding mechanism can be 

The trusted resource mechanisms can be variously imple- 10 un P lcmented so as t0 forward a copy of the received agent, 

mented. Typically, the mechanisms are implemented as so as to enable the fingerpnnt acquisition and/or comparison 

software to operate on/among one or more computing device mechanisms to proceed in parallel to the forwarding, 

(e.g, a personal computer, workstation or server computer), Moreover, the forwarding mechanism can be implemented 

each computing device conventionally comprising an oper- 50 as t0 support one °r more of plural destination resources, 

ating system (e.g., Unix, Linux, Windows NT or otherwise), 15 plural origin resources and supplemental, redundant or other 

a communication stack, communication hardware, processor additional trusted resources. 

(s) and other logic hardware, a memory system (e.g., one or A fingerprint acquisition mechanism acquires fingerprints 
more of cache memory, dynamic random access memory, of agents. The fingerprint acquisition mechanism can be 
mass storage, archival storage and otherwise), in selected implemented using a variety of technologies. In any 
combination(s). If implemented as software, it is to be 20 implementation, the technology preferably provides a fin- 
understood that any one or more of the trusted resource gerprint that is actually or practically unique, agent to agent, 
mechanisms can be implemented as an integrated software An example technology is a one-way hash function (e.g., 
object or a collection of discrete software objects in an MD5). A one-way hash function, using the agent as input, 
object oriented software program, or as a single integrated produces a hash signature that not only is unique, but also 
software program, or otherwise. Similarly, any combination 25 tends to preclude reverse engineering, 
of resource mechanisms can be implemented to share soft- The fingerprint acquisition mechanism preferably is 
ware objects, modules or other software components. implemented to fingerprint based on fixed information of the 
Moreover, it is to be understood that any one or more of the software agent. For example, the fingerprint may be based 
trusted resource mechanisms, in whole, in part or in on the address information (e.g., one or more of origin, 
redundancy, can be implemented in hardware (e.g., includ- 30 destination and trusted resource addresses) and/or the infor- 
ing as firmware), with or without software components). In mation and entrusted task(s) associated with the agent 
that regard, as described above respecting the trusted (and/or other essential transactional information). However, 
resource generally, any such mechanism can be imple- it is to be understood that the mechanism can be imple- 
mented in/at one physical location or among a plurality of mented to fingerprint based on the agent's variable 
physical locations in or associated with the computing 35 information, alone or together with fixed information (see 
environment. discussion herein respecting the software agent's fixed and 

A receipt mechanism enables the trusted resource to variable fields). (The below described TR rules preferably 

receive in the computing environment, particularly to are not employed in acquiring a fingerprint.) Indeed, the 

receive software agents associated with an origin resource. fingerprint can include, or simply be, the entire agent itself. 

The origin resource, in such case, typically is enabled to 40 The fingerprint acquisition mechanism can be triggered 

exploit the trusted resource's services, with or without using one or more approaches, based on the implementation, 

payment of money, transfer for value, or other consideration. In one embodiment, the mechanism is triggered by the 

(Hereinafter, origin resources so enabled to exploit a trusted receipt mechanism for selected agents. For example, the 

resource's services are sometimes referred to as having receipt mechanism can be implemented to trigger the fin- 

"subscribed", as having a "subscription" or some variant 45 gerprint acquisition mechanism only when a filter compo- 

thereof; similarly, origin resources having a subscription are nent of a receipt mechanism determines that a received agent 

sometimes referred to as "subscribing origin resources" and is subscribing. In another embodiment, the fingerprint acqui- 

the associated software agents are sometimes referred to as sition mechanism is triggered by the receipt mechanism for 

"subscribing agents".) all received agents. In this latter case, if the trusted resources 

Software agents are launched into the computing envi- 50 can receive other than subscribing agents, the fingerprint 

ronment for various purposes, including for various verifi- acquisition mechanism may be implemented to determine or 

cation purposes. Because a trusted resource may receive to contribute to a determination of whether a received agent 

agents that are unrelated to its verification services, a TR's is subscribing. In other embodiments, the fingerprint acqui- 

receipt mechanism preferably comprises a filter component sition mechanism is self triggering, or is triggered by some 

that determines which received agents are subscribing, 55 mechanism other than the receipt mechanism. In any case, 

including by analyzing the configuration and/or specifica- the receipt of at least selected agents preferably results in 

lion of the agent (e.g., for a verification enabled flag). triggering the fingerprint acquisition mechanism. 

Although a filter may be implemented, it is to be understood A fingerprint storage mechanism effects the storage and 

that a filter need not be implemented, particularly where, for retrieval of fingerprints. The storage mechanism preferably 

example, the trusted resource is implemented in the com- 60 is implemented using a memory system (e.g., one or more of 

puting environment so as to receive only subscribing agents. cache memory, dynamic random access memory, mass 

The receipt mechanism preferably also is enabled to storage, archival storage and otherwise, whether lumped or 

determine whether an agent is newly received (e.g., from the distributed). The storage mechanism preferably also 

origin resource) or is returning (e.g., from a destination includes a control component. In a typical embodiment, the 

resource). The receipt mechanism signifies its determination 65 control component provides for storing an acquired finger- 

with respect to the agent, e.g., by setting/resetting a receipt print in, and retrieving the fingerprint from, a predetermined 

flag in or associated with the agent. location of the memory system, e.g., as a fingerprint file/ 
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entry in a fingerprint database. In one example, the finger- example, the verification return can comprise a verification 

print storage mechanism is implemented to store only those flag that is set or reset based on whether or not corruption is 

fingerprints that correspond to subscribing agents, based on detected (e.g., whether or not the task has been successfully 

a subscription determination it performs or some other completed). As another example, the verification return can 

mechanism performs (e.g., in parallel with the 5 comprise detail respecting the results of any verification 

fingerprinting). operations conducted at the trusted resource. As yet another 

A fingerprint storage mechanism can be triggered using example, the verification return can comprise some or all, or 

one or more approaches, based on the implementation. In representations, of information about, or results of, the 

one embodiment, the mechanism is triggered by the receipt agent's activities (e.g., information gathered by, or resulting 

mechanism for selected agents. For example, the receipt to from, performance of an entrusted task). As a further 

mechanism can be implemented to trigger the fingerprint example, the verification return can comprise information or 

storage mechanism only when a filter component of a receipt direction directed to enable or support corrective action. It is 

mechanism determines that a received agent is subscribing. to be understood that the verification return can comprise 

In another embodiment, the fingerprint storage mechanism combination^) of the above, or combination(s) of any of one 

is triggered by the receipt mechanism for all received agents. 15 or more of the above with other return. 

In this latter case, if the trusted resources can receive other The verification return typically is directed to origin 

than subscribing agents, the storage mechanism may be resource(s). However, verification returns can be directed to 

implemented to determine or to contribute to a determina- the destination resources, as well as to other trusted 

tion of whether a received agent is subscribing. In yet resources. More specifically, the verification return is 

another embodiment, the fingerprint storage mechanism is 20 directed to those resources to which the agent or its activities 

triggered by the fingerprint acquisition mechanism for are relevant. An agent or its activities generally are relevant 

received agents. In this latter embodiment, the mechanism to an origin resource if the agent at some point became 

may be implemented to store only those fingerprints that entrusted with tasks and associated information relevant to 

correspond to subscribing agents, e.g., based on a subscrip- the origin resource. 

tion determination it or some other mechanism performs. 25 The verification return mechanism can be triggered using 
A fingerprint comparison mechanism provides for com- one or more approaches, based on the implementation. In 
paring acquired fingerprints of a software agent so as to one embodiment, the mechanism is triggered by the finger- 
identify differences or other irregularities that may indicate print comparison mechanism and verification return is 
potential corruption. In a typical embodiment, the compari- directed whether or not the comparison of fingerprints yields 
son mechanism compares (a) a previously-acquired finger- 30 any irregularities. 

print of a software agent that has returned at the trusted A timer mechanism comprises timer components and 

resource to (b) the agent's current fingerprint, as newly monitoring components. In a typical embodiment, the timer 

acquired by the fingerprint acquisition mechanism. components keep the time elapsed following the occurrence 

However, it is to be recognized that, in other of one or more selected first classes of timer events and until 

embodiments, the time characteristic (e.g., "previously 35 the occurrence of one or more selected second classes of 

acquired" and "current", above) of acquisition and compari- timer events, such first and second classes of timer events 

son may be substantially or entirely inapplicable. In being entirely the same, entirely different or the same in part, 

particular, it is contemplated that a software agent be subject Such timer events typically reflect the software agent, its 

to verification operations relating to at least two verification information and task(s), and/or the origin or destination 

events: the first verification event relying on the agent's state 40 resources, 

absent any interaction with a resource that performs a task, A monitoring component preferably monitors an associ- 
and the second verification event relying on the agent's state ated timer component for elapsed time. As an example, a 
subject to any interaction with a resource that performs a monitoring component can be implemented to monitor an 
task. The two verification events, in certain embodiments in associated, timer for elapsed time exceeding a predeter- 
accordance with the invention, may be entirely or substan- 45 mined maximum period (the period being sometimes 
tially without a time difference. referred to as a "time-out period" and the timer event being 
A verification return mechanism generates notices, reports sometimes referred to as a "time-out"). Moreover, respon- 
or other return relevant to verification of the agent and its sive to a time-out, the monitoring component preferably 
activities (hereinafter referred to individually and collec- effects a time-out message, which message preferably has 
lively as "verification return"). The verification return 50 content and parameters that reflect the circumstances (e.g., 
mechanism can be variously implemented. As an example, the agent, its information and task(s), and/or the origin or 
the verification return mechanism can be implemented so as destination resources). In one example embodiment, a moni- 
to direct selected verification return(s) to a particular toring component's time-out message comprises (a) a time- 
resource. Moreover, the verification return mechanism can out flag, (b) an agent's original fingerprint and/or other 
be implemented to so direct returns via return of the original 55 information selected to identify the software agent, and (c) 
agent, or by return separate from the original agent, or other information, e.g., respecting the computing environ- 
otherwise. As to the first case, the verification return mecha- ment's status, any news regarding the agent's destination 
nism preferably generates the return, providing same to a resource or otherwise. In this and other embodiments, the 
forwarding mechanism. As to the second case, the verifica- time-out message preferably comprises sufficient informa- 
tion re turn mechanism preferably supports any one or more, 60 tion and direction so as to enable corrective or other appro- 
in any combination, of (a) generating and launching its own priate action. 

return-bearing agents, such launch being preferably by, or in The time-out message preferably is directed to the veri- 

coordination with, the forwarding mechanism, and (b) gen- fication return mechanism, in response to which the return 

erating and sending some non-agent message, and (c) other mechanism generates and directs appropriate verification 

solutions. 65 return. In this manner, any particular time-out message is 

In addition, the verification return can be variously made known to the one or more resources for which the 

configured, in accordance with the invention. As an message holds relevance. As an example, in a typical 
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embodiment, verification return is directed to an origin The "TR rules preferably are inaccessible to selected parts 

resource if a software agent fails to return properly from of the computing environment. As a typical example, a 

interaction with a destination resource within the lime-out subscribing software agent launched by, and has TR rules 

period, the time-out period being measured from a prede- originating at, an OR preferably is configured, specified or 

termined event, and such predetermined event comprising, 5 processed so that such rules are inaccessible at/by the 

e.g., the first receipt of the software agent at/by the trusted destination resource. In such example, the inaccessibility 

resource. Notwithstanding this example, and in keeping with pre ferably is effected at/by the trusted resource. The trusted 

previous descriptions it is to be understood that verification re$ource referabl renders lhe TO mles inaccessible by 

return responsive and appropriate to the above or other M { maski enoodin erjcryptirjg or some other 

time-out messages can be directed to any resource(s), r . . ~ . ° . i_ ■ j 

including destination resources or other, or other parts of, 10 a PP ro P nate processing. Doiog so protects the rules, guards 

trusted resource(s) against improper manipulation of the rules and precludes 

Hie timer and monitoring components can be triggered J™* the ™|~ to com ^ entrusted tasks and associated 

using one or more approaches, depending on the implemen- information (e.g., corruption based on determining from the 

talion. In an example embodiment, a timer component is ™ the permissible values or states for a given variable 

activated by the receipt mechanism's determination that an 15 fielc 0- In short > tne TO mles and related information are 

agent (e.g., a subscribing agent) is newly received or return- rendered inaccessible to assist in precluding (and in 

ing. In another example embodiment, a timer component is identifying) corruption of the agent and its activities, 

activated by a forwarding mechanism's direction of a A logging mechanism logs information respecting all or 

received agent, e.g., to a destination resource, selected events that occur in connection with a software 

In any embodiment, a timer component preferably sup- 20 agent. To do so, the logging mechanism preferably (a) saves 
ports being de-activated. To illustrate this latter the event information, e.g., in a separate log, in the agent's 
embodiment, a timer component associated with a first agent fingerprint file(s) or database, or in some other database of 
preferably is de-activated if the agent or some other return agent-related information, (b) provides current or saved 
arrives prior to a time-out. Preferably, the timer component event information for use, e.g., to track historical activities 
is de-activated if the agent and its arrival are both proper. 25 of software agents, and/or (c) processes event information 
That is, de-activation generally implicates a determination based on selected criteria so as to provide reports, e.g., about 
that an agent has properly returned to the trusted resource, one agent or about groups or types of agents. As examples, 
which determination can be accomplished by the receipt the logging mechanism can be implemented to log event 
mechanism (e.g., upon identification of an agent return information that includes, or can be processed to provide 
event), by the fingerprint acquisition mechanism (e.g., upon 30 reports respecting, the frequency a given agent type is used, 
successful acquisition of the agent's current fingerprint), by the overall agent traffic and the historical return times 
the fingerprint storage mechanism (e.g. upon successful (overall or by type or otherwise). The logging mechanism 
retrieval of the agent's previously-acquired fingerprint), or preferably is implemented, among other purposes, to pro- 
otherwise. In any such embodiment, it is preferred that an vide input to the housekeeping and administration mecha- 
associated monitoring component(s) be suitably triggered 35 nisms. 

and controlled. A housekeeping mechanism provides for maintenance of 
A rules mechanism executes trusted resource rules the various mechanisms and components comprising the 
(sometimes referred to herein as "TR rules"). As an trusted resource, as well as other similar functions support- 
example, the TR rules originate from an origin resource and ing the verification services. As an example, the housekeep- 
are provided at the trusted resource via a software agent 40 ing mechanism preferably is implemented to delete finger- 
relevant to the origin resource, the provision preferably print entries, records, files, databases and other stored 
occurring when the software agent first interacts with the information, in whole or in part, based on predetermined 
trusted resource. As another example, the TR rules can factors (e.g., completed verification service or staleness). As 
originate at the trusted resource itself. In this latter example, another example, the housekeeping mechanism is imple- 
the TR rules can be established responsive (a) to received 45 mented to update fingerprint entries, records, files, databases 
software agent's information and/or task(s), (b) to previous and other stored information, in whole or in part, based on 
exploitation of the TR's services by the origin resource, or predetermined factors (e.g., so as to move information to an 
(c) to other inputs, configurations or (d) to combinations of inactive agent file, such that the information can be consid- 
(a)-(c) or otherwise. ered for reporting purposes performed respecting the file 
The rules mechanism may be variously implemented for 50 contents from time to time). As yet another example, the 
executing theTR rules. As an example, it can execute theTR housekeeping mechanism is implemented to modify time- 
rules either (a) in association with the software agent's first out periods employed by the timer mechanism, e.g., based 
interaction with the trusted resource or (b) upon return of the on historical return limes for a given agent type (such 
agent from the destination resource, or (c) both. Moreover, information typically being provided by the logging 
it can execute the TR rules using a software agents' fixed or 55 mechanism), and/or based on other parameters, such as the 
variable information, other information, or combinations of destination resource or the destination resource type, and/or 
same. the chronological or calendar context (i.e., time of day, day 

The TR rules enable selected operations. These operations of the week or season) in which the agent is active, 

include, for example, (a) operations that ensure the TR rules An administration mechanism provides for ministerial 

themselves are not corrupted and (b) operations that check 60 functions peripheral to the verification services. As an 

the software agent for corruption, e.g., of variable informa- example, the administration mechanism preferably is imple- 

tion. As to the latter, in one example embodiment, the TR mented to provide for invoicing and accounting. As to 

rules are implemented to specify data constraints (e.g., invoicing, the administration mechanism can be variously 

ranges, types, etc.) applicable to the variable information implemented. To illustrate, fees may be charged (via the 

such that, upon the agent's return to the trusted server, the 65 origin resource) in connection with use of the verification 

TR rules are executed to check the actual variable informa- service, such fees being established on one or more of (i) a 

tion against such constraints. per agent basis, (ii) a per destination resource basis, (iii) a 
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type or nature of agent basis, (iv) a type or nature of origin firmware), so as to render the mechanism itself entirely or 

resource basis, (v) a type or nature of destination resource substantially non-corruptible. In that implementation, it is 

basis, (vi) a type or nature of TR rules basis, (vii) the basis preferred that other trusted resource mechanisms, as well as 

of a combination of one or more of these bases, (vii) on some software components thereof (e.g., the operating system and 

other basis or bases alone or in combination with one or 5 communication stack) are also implemented, in whole, in 

more of these described bases The admmistration mecha- ^ or in redundancv> in hardware (e.g., including as 

nism typically obtains from the logging mechanism, at least firmware) . S o implementing these mechanisms (and 

in part, information relevant to invoicing. ' v , x . , u omo V a UU 

As another example, the administration mechanism pref- 3^1^ P r T ™£ TTt 

erably is implemented to provide services that assess various subslantl , aU y P olec * d fro ™ corruption and/or (b) the trusted 

performance statistics or other parameters characterizing the 10 * source s m P hcaled mechanism(s) to be compared to, e.g., 

computing environment. In doing so, the administration firmware copies from time to time so that, if any corruption 

mechanism preferably is enabled to receive input from 15 djsc overed, corrective measures can be invoked. Typical 

subscribing origin resources (or, at least those origin corrective measures include repairing software, e.g., by 

resources choosing to exploit any such assessment service), reloading objects, by deleting any extraneous code, by 

such input including, e.g., identification of the statistics/ 15 application of code comparison and correction algorithms or 

parameters of interest and any restrictions or selections for similar routines, and/or by other conventional approaches, 

accomplishing/reporting the assessment results. To whether automatically or by human initiation, such as by a 

illustrate, the administration mechanism can be imple- system operator. 

mented to identify and track other verification-directed An encryption mechanism provides for encrypting and 

offerings that might compete with, or substitute for, the 20 decrypting all or part(s) of software agents, verification 

trusted resource's verification services. To do so, the admin- returns and other relevant messages received by, or to be 

istration mechanism can qualify selected performance char- forwarded from, a trusted resource. An encryption mecha- 

acteristics (e.g., usage) of agents that interact with the nism can be variously implemented. As an example, an 

competing/substitute offerings. As another illustration, the encryption mechanism can be implemented using public key 

administration mechanism can be implemented to assess the 25 encryption plus certificates. So implemented, the encryption 

computing environment's loading. In doing so, the origin mechanism assists in addressing various risks that tend to be 

resource's input can include a request — e.g., based on one or inherent in the computing environment, including: (a) the 

more levels of prevailing load — to delay or accelerate or risk that intermediaries intercept communications in order to 

time one or more of its agents traverse from the trusted obtain sensitive or secret information (often referred to as 

resource (e.g., to either the destination or origin resource), as 30 "eavesdropping"); (b) the risk of corruption by intermedi- 

well as to request progress reports) as to the status of the aries changing information/tasks in communications (often 

traverse (e.g., the origin resource can choose no progress referred to as "manipulation"); and (c) the risk that the origin 

reporting, or can choose to have reports of delay and/or of resource or the destination resource is not authentic (often 

traverse initiation). referred to as "impersonation"). However, any encryption 

A security mechanism provides for securing selected 35 mechanism generally is ineffective to protect a software 

portions of the computing environment from corruption. The agent at all times before it is forwarded from a resource or 

security mechanism can be variously implemented. As an after it is received at a resource (i.e., before encryption and 

example, the security mechanism can be implemented to after decryption), 

process received agents, so as to protect one or more of the Operation of the TR Mechanisms 

software agent, the origin resource, the destination resource 40 The trusted resource mechanisms preferably are imple- 

and the trusted resource from any corrupting influences mented for operational coordination among either all or 

potentially present in the agent itself, regardless of the selected such mechanisms. This coordination can engender 

source (e.g., sourced incident to exercising the computing parallel, sequential, or other operation among mechanisms, 

environment). Toward accomplishing that end, the security depending on their respective implementations. In a typical 

mechanism typically is enabled to remove, disable or oth- 45 embodiment, for example, the storage mechanism is used in 

erwise render ineffective any or all of a received agent that cooperation with the fingerprint acquisition and comparison 

may be corrupted or corrupting. Such a mechanism prefer- mechanisms: the fingerprint acquisition mechanism acquires 

ably includes monitoring firmware and/or other hardware the fingerprint of a newly-arriving agent, whereupon the 

which is used to identify agents and other potentially execut- storage mechanism stores the fingerprint (e.g., in the trusted 

able code that may be corrupted. 50 resource's memory system) so that, upon the agent's return 

As another example, the security mechanism can be to the trusted resource, the storage mechanism can retrieve 

implemented so that the trusted resource is enabled to the previously-acquired fingerprint for provision to the com- 

execute only a specified procedure or set of procedures, parison mechanism, the comparison mechanism comparing 

which procedures are identified by the information the previously-acquired fingerprint with the agent's current 

processed, by steps or combinations of steps in the 55 fingerprint, such current fingerprint being acquired by the 

procedure, by the results they generate, or otherwise. Such fingerprint acquisition mechanism in anticipation of the 

non-corruptible systems include, e.g., capability -based sys- comparison, e.g., to verify the agent, 

terns or architectures. Thereunder, each task is assigned a Also in this typical embodiment, the fingerprint compari- 

ticket (or other identifier) and only properly ticketed tasks son mechanism triggers the verification return mechanism to 

are executable. For further information regarding capability 60 generate verification return(s). Such trigger and generation 

based systems reference is made to Welbey, M. V. and preferably is provided whether or not the comparison detects 

Needham, R. M, "The Cambridge CAP Computer and Its corruption. If corruption is detected, however, the fingerprint 

Operating System," Operating and Programming Systems comparison mechanism preferably provides information to 

Series, ed. P. J. Denning, 1979, N.Y., North Holland, which the verification return mechanism. Using such information, 

is incorporated herein by reference. 65 the verification return mechanism preferably is enabled to 

The security mechanism can be implemented, in whole, in generate verification return structured to inform of the 

part or in redundancy, in hardware (e.g., including as corruption and, preferably, also to enable corrective action. 
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The comparison mechanism's information can include, as Variable fields typically support operational flags (e.g., a 

non-exhaustive examples, each of the compared fingerprints new/old flag), time flags (e.g., time/date of receipt 

and the differences therebetween. The verification return can forwarding, and/or return), rules data (eg verification 

mclude these in the form provided or in processed form return data)> task . re l ale d information, task-related code, or 

ei^^S^H T^'T aCt , I ° D) - , veni \ caUon 5 other variable information. The variable information gener- 

f°™**n. e.g., elapsed time all mcludes ^formation thal ma ch ^ * mjs . 

and any time-outs, the destination resource (e.g., by address) c1 -lu u~.u- _ • . . , 

and any other data that the trusted resource may have learned S^^TT^ °* T " nDB * 10n Wlth agenl S 

about the agent or about the corruption. activities. Such activities including, for example, one or 

Further in this typical embodiment, the verification return more ° f the age 1 nl a ™ mg al me DR > lhe a S enl accomplish- 

mechanism typically coordinates with the forwarding 10 in S ^ ^™ st ^ tas ^s) or the agent arriving (from the OR 

mechanism so as to direct the return to the origin resource or the DR ' al the TO - lne va nable information may 

for which verification is relevant. Such direction is typically change, such change typically is limited to certain, permis- 

accomplished by forwarding the return as part of the verified su ^ e um i ts - 

agent, such agent itself being forwarded by the forwarding ^ a S ent according to the present invention preferably 

mechanism. In doing so, it is contemplated that the agent 15 supports TR rules. TR rules typically enable selected 

carrying the return is processed by the encryption mecha- operations. These operations include, for example, ensuring 

nism so as to protect the agent from corrupting influences in that the TR rules themselves are not corrupted and/or 

traversing to the origin resource. In doing so, it is also checking for appropriate modifications of variable informa- 

contemplated that the agent is processed, e.g., by the secu- tion. As to the latter, in one example embodiment, the TR 

rity mechanism, so as to protect one or more of the verifi- 20 rules are implemented to specify data constraints (e.g., 

cation return, the software agent, the origin resource and the ranges, types, etc.) applicable to the variable information 

trusted resource from any corrupting influences potentially such that, upon the agent's return to the trusted server, the 

present in the returned agent itself, e.g., by removing, TR rules are executed to check the actual variable informa- 

disabling or otherwise making ineffective any or all of the tion against such constraints. 

agent that may be corrupted or corrupting. 25 Through its fields, the software agent contains informa- 
In this typical embodiment, the timer mechanism's timer tion and entrusted task(s). Any entrusted tasks generally are 
and monitoring components are employed. A timer compo- contained in fixed fields in the form of code that is executed 
nent generally is activated in connection with the software at or in connection with a destination resource. This execu- 
agent's first arrival at the trusted resource (e.g., when the tion typically results in changes in the contents of one or 
agent's state is free of any interaction with the destination 30 more variable fields. As an example, the execution code can 
resource). To illustrate, the timer component preferably is modify selected variable information or add new data to the 
activated based on the forwarding of the agent to the agent, including data obtained from or otherwise associated 
destination resource. with the destination resource. The execution code can also 
With activation of a timer component, at least one asso- rely on associated information contained in the software 
ciated monitoring component preferably is activated so as to 35 agent. Such associated information generally is also con- 
monitor that timer component. To illustrate, a monitoring tained in fixed fields, in the form of data. However, such 
component preferably is activated to monitor the timely and information may instead (or also) be contained in variable 
proper return of the software agent from the destination fields. 

resource, such monitoring being against a predetermined Software agents according to the present invention can be 

return time-out period. As such, if the agent fails to properly 40 implemented to accomplish more than one task and/or to 

return before a return time-out occurs, the monitoring com- interact with more than one destination resource, 

ponent effects a timeout message, which message indicates Accordingly, forwarding of the agent can be accomplished 

the return time-out event through content and parameters in various ways. As an example, a software agent can have 

appropriate to the circumstances. The time-out message associated therewith tasks Tl, T2, T3, and T4, one each to 

typically is used in forwarding a verification return. 45 be executed at destination resources DR1, DR2, DR3, and 

In other illustrative examples of coordination: (a) the DR4, respectively. In one implementation, a trusted resource 

storage mechanism coordinates with the housekeeping TR1 forwards copies of the agent in parallel to each of the 

mechanism so as to purge stale fingerprints, and (b) the destination resources. In another implementation, a trusted 

logging mechanism preferably is implemented, among other resource TR1 forwards the agent sequentially to each of the 

purposes, to provide input to the housekeeping and admin- 50 destination resources, so that the respective tasks are per- 

istration mechanisms so that the latter mechanisms have formed in either a predetermined sequence or based on 

information enabling them to set/update time-out periods availability of resources. In yet another embodiment, the 

and to compute invoices, respectively. trusted resource TR1 combines parallel and sequential for- 

Software Agent warding. 

A software agent of the present invention is implemented 55 The trusted resource(s) involved in verifying agents hav- 

so as to enable verification using the apparatus and methods ing plural tasks and/or destination resources may be vari- 

of this invention. Any such agent preferably has one or more ously implemented as to verification operations. As an 

fixed and variable fields. Fixed fields typically support example, trusted resource(s) overseeing sequential perfor- 

addresses, rules, data, code, security protocols or other fixed mance of tasks at destination resource(s) may be imple- 

information (information that does not or should not change 60 mented to signal corruption (i.e., via verification return) (a) 

regardless of the task(s) the agent is entrusted to as to the entire sequence if any task is associated with failed 

accomplish). As an example, the fixed field addresses can verification, (b) as to only the sequential task associated with 

include addresses of origin, destination and trusted failed verification, or (c) as to the sequential task associated 

resources, such addresses being appropriate to the comput- with failed verification and all subsequent tasks in sequence, 

ing environment. Through these addresses, the software 65 As yet another example, trusted resource(s) overseeing 

agent properly exercising the computing environment so as parallel performance of tasks at destination resources) may 

to traverse among the OR, DR, and TR. be implemented to signal corruption (a) as to only those 
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tasks associated with failed verification or (b) as to all tasks, 106 in communication with (and preferably being a part of) 

if any is associated with failed verification. a computing environment 108. The sites 102, 104 and 106 

Particularly in embodiments involving an agent associ- communicate in the computing environment 108 via com- 

ated with plural tasks and/or destination resources, plural munication paths 110. The sites 102, 104 and 106 

trusted resources can be employed. Such employ generally 5 correspond, respectively to an origin resource, a trusted 

is implemented via appropriate configuration of the agent resource and a destination resource. The computing envi- 

(e.g., a flag enabling plural TRs and/or addresses for plural ronment 108 typically is part of an Internet. (The origin site, 

TRs) and/or appropriate configuration of the trusted resource trusted site and destination site sometimes are referred to 

(s) to which the agent subscribes. As an example, if the agent herein, respectively as "OS", "TS" and "DS".) 

subscribes to only one trusted resource TR1, that subscribed 10 Generally, the trusted site 104 is a computing device or 

resource can itself employ one or more additional, inter- computing system (two or more computing devices) that, 

posed trusted resources. To do so, TR1 typically itself together with software, act as a server. If the environment 

modifies the agent's trusted resource address information so 108 is an Internet, the trusted site 104 is an Internet server, 

as to forward the agent, e.g., to each such interposed trusted The origin and destination sites 102 and 106 can be any site, 

resource, whether for parallel, sequential or other perfor- 15 including, for example, a standalone PC in a user's home or 

mance. In this example, the agent typically will have set a a node of a LAN-based computing environment, or any 

flag indicating enablement of plural TRs; it being other localized/closed computing environment with commu- 

understood, however, that such flag may be omitted without nication access to the environment 108 so as to link it to 

departing from the principles of the invention. unrelated computer platforms, environments or other instal- 

Use of interposed trusted resource(s) generally has impli- 20 lations. 

cations respecting treatment of an agent's TR rules by the Referring to FIG. 2, an example trusted site 200 is shown 

subscribed trusted resource(s). As previously described, a to include a processor ("P") 202, a memory system 

subscribed trusted resource generally is implemented to ("MEMORY") 204 coupled with the processor 202 via 

exercise an agent's TR rules. To do so, the subscribed trusted coupling 206. The processor can be any digital processing 

resource is enabled access to the TR rules. Accordingly, if 25 device including, without limitation, microprocessors, 

interposed trusted resource(s) are to employ the TR rules microcontrollers, digital signal processors or the like manu- 

such resources preferably are provided access. As such, it is factured by Intel Corporation, Motorola Corporation, Texas 

preferred that the subscribed trusted resource refrain from Instruments, Inc., IBM, AMD, Cyrix, or any other manu- 

stripping the TR rules from the agent. While stripping facturer of digital processing devices. The trusted site 200 

generally is not preferred, it is to be understood that, under 30 can also include a variety peripherals including, without 

specific circumstances (e.g., where TR rules are locally limitations, printers, display terminals, battery backup 

provided at an interposed TR or where the TR rules ulti- devices, and power conditioning devices, 

mately are performed at the subscriber TR), stripping of the The trusted server 200 also includes software 212. The 

TR rules may be implemented. Similarly as to masking, software preferably resides in the memory system 204. The 

encoding, encrypting or other processing of the TR rules 35 software 212 includes an operating system 218 which can be 

provided at the subscribed trusted resource, it is preferred any operating system capable of executing instructions to 

that, where the interposed trusted resource(s) are to perform effectuate the necessary tasks required of the trusted server 

the TR rules, such resources) be enabled to unmask, 200. Suitable operating systems include, without limitation, 

decode, decrypt (e.g., by public key techniques) or otherwise windowing operating systems, UNIX-based operating sys- 

reverse process. Moreover, even where any interposed 40 terns or any other operating system, 

trusted resource(s) acts to protect the TR rules, the sub- The software 212 also includes a software agent verifi- 

scribed and interposed trusted resources preferably coordi- cation system 220 for verifying software agents and their 

nate so that the subscribed trusted resource maintains its activities. The software 212 can also include a security 

access. system 222 for protecting the TS from viruses or other 

In any case wherein an agent supports plural tasks, a 45 corrupting software mechanisms. It is to be recognized that 

trusted resource can be implemented to terminate, suspend the security system can be integrated in the verification 

or otherwise disable remaining task(s) in the event that any system, without departing from the principles of the inven- 

task is associated with a verification failure. In cases of tion. 

disablement, the trusted resource preferably is enabled to The TS 200 also includes an input port 224 and an output 

attempt correction of agent corruption. Such correction 50 port 230. The input port 224 is coupled both with the 

typically is based on the TR fingerprint files associated with processor 202 (via coupling 226) and with the environment 

the agent. Moreover, such correction, if so implemented, can 108 (via path 228). The output port 230 is coupled both with 

be based on additional input, e.g., from the implicated origin the processor 202 (via coupling 232) and with the environ- 

resource, such input generally being responsive to a verifi- ment 108 (via path 234). 

cation return directed thereto relating to the verification 55 Referring now to FIG. 3, a flowchart 300 presents a 

failure. If correction is accomplished, the trusted resource preferred set of steps for implementing the verification 

preferably notifies the implicated origin resource OS and system 220 on the trusted server 200. The flowchart 300 

enables the previously- disabled, remaining tasks. includes a nominal start 302 which generally is initiated on 

Thus, the present invention contemplates the employ of system startup. The verification system 220 is enabled to log 

pluralities of trusted resources, whereby verification of 60 all software agent activities in a log file in a log update step 

agents and agent activities, is made efficient and productive 304. When a software agent is directed to the trusted server 

based on cooperation and spreading (e.g., dynamically) of 200, the verification system 220 receives the software agent 

verification operations among the trusted resources. in a receive step 306, and optionally performs a security 

The Embodiments of the Figures check of the agent, in step 308, toward maintaining TS 

Referring now to FIG. 1, a system 100 implementing the 65 integrity, 

apparatus and methods of the invention is shown to include Once received and optionally security tested, the verifi- 

an origin site 102, a trusted site 104 and a destination site cation software executes (or saves) the TR rules that form a 
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pari of the fixed code portion of the agent, and also strips the 
agent of the TR rules in step 309 (or otherwise protects such 
rules). 

In step 310, the system 220 fingerprints the agent. 

In step 312, the verification software 220 activates a 5 
return timer for received software agent(s). The system 220 
performs a time-out step 314 which checks for a time-out 
condition for the agent(s) in the fingerprint file. The time-out 
step 314 can be an interrupt routine that becomes active if 
and when a time-out condition is encountered, but can also 10 
be a routine that scans the fingerprint file for a time-out 
condition at some pre -determined interval. If a lime-out 
condition is encountered, control is transferred along a "yes" 
branch 316 to a generate time out notice step 318 and to a 
send notice step 320. The steps 318 and 320 generate and 15 
send a time-out notice to the appropriate resource (e.g., an 
origin site 102). Control is then transferred back to the 
update log step 304, and the process continues monitoring 
agents. 

If a time-out condition is not encountered in step 314, 20 
control is transferred along a "no" branch 322 to step 324 
which tests whether the received agent is "new". If the agent 
is "new", control is transferred along a "yes" branch 326 to 
a save fingerprint step 328 which stores the agent fingerprint, 
e.g., in a fingerprint file. After fingerprint storage, the system 25 
220 performs a set timer step 330 which turns the agent 
return timer to an ON condition. Next, the "yes" branch 326 
performs a set old step 332 which adds information to the 
agent so that the system 220 will be able to identify the agent 
as an old agent upon the agent's return to the system. 30 
Preferably, the set old step 332 sets a flag bit in the agent 
from "off' to "on" (0—1 or l-*0). (Additionally, the flag 
may include a security algorithm such as a lock and key to 
secure against tampering.) The "yes" branch 326 then for- 
wards the agent to its destination in a send agent step 334. 35 
Control is then transferred back to the update log step 304, 
and the process continues for monitoring agents. 

In step 324, if the agent is "old" (i.e., not "new", e.g., 
because the old agent flag was previously set via a step 332), 
control is transferred along a "no" branch 336 to a second set 40 
timer step 338 which turns the agent return timer to an OFF 
condition. The "no" branch 336 performs a retrieve original 
fingerprint step 340 which searches for the previously 
acquired/stored fingerprint associated with the agent and, if 
the fingerprint is located, retrieves the original agent finger- 45 
print. The original fingerprint and current fingerprint are 
then compared in a fingerprint compare step 342. The 
comparison step 342 determines whether the information in 
the original fingerprint sufficiently agrees with the informa- 
tion return fingerprint. 50 

In step 343, the TR rules are executed against the returned 
data values. If the rules are satisfied and the fingerprints 
favorably compare, it is indicated that the agent's task(s) 
have been successfully completed. Preferably, the destina- 
tion site has written completion information into the agent so 55 
that the comparison of fingerprints and the execution of the 
rules to check variable data can establish successful comple- 
tion of the agent's task. 

Suppose the agent is designed to transfer a certain sum 
from one account to another account at the client's bank, 60 
MYBANK. The agent would have a TS address, a 
MYBANK address, the account numbers and the amount to 
be transferred. When the agent arrives at the TS, the TS 
verification system creates a file which contains a unique 
identifier for the agent and stores transaction information. 65 
Preferably, the destination site has software designed to 
write into the software agent a record of the transaction 
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executed by the destination site before sending the agent 
back to the TS for verification. When the agent returns, the 
TS verification system compares the original transaction 
information to the transaction information in the returning 
agent and to the log information appended to the agent by 
the destination site. 

Because the fingerprint, profile or signature of a software 
agent comprises almost exclusively fixed information of the 
agent (i.e., information in non-variable fields or fields which 
should not be modified during software agent activity), the 
verification checking algorithms resident at/in the TS will be 
capable of checking for errors or discrepancies in any 
portion of the fixed fields of the agent. Additionally, the 
agent may include fixed rules that contain information 
concerning the manner in which certain variable fields can 
be altered, e.g., at/by the destination site. The rules could tell 
the TS permitted ranges that a data variable could assume, 
could tell the TS what type of additional code the agent can 
acquire, could tell the TS what type of code should have 
been extracted from the agent, or could tell the TS any other 
pertinent information about the manner in which the variable 
field of the agent can be modified. 

After the comparison step 342 compares the two agent 
fingerprints and determines the comparison results, the 
results are passed to a rules checking step 343 whose results 
are passed to a generate message step 344 which takes the 
comparison results and checking results and generates an 
appropriate notice. If the comparison and checking show no 
irregularities, then the message step 344 would generate a 
successfully completed message or notice (i.e., a verification 
return). If the comparison and checking show irregularities, 
then the message step 344 would generate a message or 
notice informing, e.g., the origin site, of the irregularity. 

The successfully completed message can include detailed 
information about the agent or simply an agent identifier so 
that the origin site can update its records. The messages 
informing the origin site of an irregularity would preferably 
contain all information necessary and sufficient for the 
origin site to take immediate corrective action. Such infor- 
mation can include both fingerprints along with all timing 
information tracked by the verification system. The TS can 
also include routine(s) for notification of the proper authori- 
ties for handling such irregularities such as bank 
commissions, federal agencies, state agencies or the like. 

Once the appropriate notice has been generated, the "no" 
branch 336 can optionally remove the agent's fingerprint 
from the fingerprint file, move the fingerprint to an inactive 
agent file, or flag the agent so that the retrieve step 340 will 
skip it during file searching, or otherwise, all provided in a 
modify file step 346. The notice is then sent to, e.g., the 
origin site in a send notice step 348. Control is then 
transferred back to the update log step 304, and the process 
continues for monitoring agents. 

It should be recognized that many of these steps can be 
combined, rendered global, or shared. As an example, the 
send and receive steps can be combined. Additionally, the 
programs flow can be redesigned and segmented into dis- 
creet objects or modules that are invoked, called or other- 
wise triggered and that exchange information during execu- 
tion. In any case, the primary operations of the flowchart 300 
are sufficiently and effectively implemented. 

Turning to FIG. 4, configuration is depicted of an example 
software agent in accordance of the present invention. The 
example agent 400 includes fixed fields 410 and variable 
fields 450. The fixed fields include address fields 412. In this 
illustration, the address fields 412 include: origin site 
address field(s) 414, trusted site address field(s) 416, and 



